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Beschreibung 

Verfahren und Anordnung zur Transformation von Quellcode 

Die Erfindung betrifft ein Verfahren und eine Anordnung zur 
Transformation von Quellcode, bei dem/der ein Quellcode, 
beispielsweise ein Java-Quellcode, in eine Darstellung in 
einer Me t a- Aus z ei chnungs sprache , beispielsweise XML, 
uberfuhrt, dort, beispielsweise mit XSLT, transf ormiert und 
dann diese in der Me ta- Aus z ei chnungs sprache formulierte 
trans formierte Darstellung in einen modif izierten Quellcode, 
beispielsweise derselben Ausgangs sprache, zuruckverwandelt 
wird. 

Aus dem Internet ist unter http : / /beautyj , berlios . de/ ein 
Java Source Code Transformation Tool BeautyJ bekannt, bei dem 
ein Java Quellcode in eine XML-Darstellung umgewandelt wird, 
mittels Sourclet API, beispielsweise durch Einfiigen von 
Leerzeichen oder geanderten Koinmentaren an bestimmten 
Stellen, „verschonert u und anschliefiend der modifizierte 
Quellcode in Java Quellcode zuriick konvertiert werden kann. 
Eine Transformation mittels XSI/T wird hier, fur diesen Zweck, 
nur vorgeschlagen, aber nicht umgesetzt. 

Die der Erfindung zugrunde liegende Aufgabe liegt nun darin, 
ein Verfahren und eine Anordnung zur Modi fikat ion von 
Quellcode anzugeben, bei dem/der eine weitergehende noch 
flexiblere und effizientere Modifikation der Quellcodes 
erreicht wird. 
HYPERLINK 

Diese Aufgabe wird hinsichtlich des Verfahrens durch die 
Merkmale des Patentanspruchs 1 und hinsichtlich der Anordnung 
durch die Merkmale des Anspruchs 10 erf indungsgemaS gelost. 
Die weiteren Anspruche betreffen bevorzugte Ausgestaltungen 
der Erfindung. 



t 
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Die Erfindung besteht im Wesentlichen darin, dass der in eine 
Meta-Auszeichnungssprache, beispielsweise XML, transf ormierte 
Quellcode mit einer in seinen Elementen standardisierten und 
vibersichtlich beschreibbaren Transformation, beispielsweise 
- 5 XSLT, derart transf ormiert wird, dass, nach einer 
Riickkonvertierung aus XML in die urspriingliche 
Programmiersprache , ein neuer Quellcode entsteht # bei dem 
nicht nur die Darstellung, sondern auch der eigentliche 
Programminhalt bzw. die Funktionalitat entsprechend den 

10 Transf ormationsvorschrif ten verandert wurde. Hierzu werden 

nur Transf ormationsregeln TR verwendet, die aus Bedingungen C 
und/ Oder Logik L und/oder Code-Fragementen CF bestehen, die 
mit Hilfe einer Transformation T zu einer Modifikation von 
CodeML in CodeML* fuhren, wodurch der Ausgangscode bspw. um 

15 eine Logging-Funktionalitat oder eine Migrierbarkeits- 
Funktionalitat erganzt wird. 

Die Erfindung wird im Folgenden anhand von in den Zeichnungen 
dargestellten Beispielen naher erlautert . Dabei zeigt 

20 

Figure 1 ein Gesamtblockdiagramm zur Erlauterung der 

Erfindung, 




Figure 2 ein Blockschaltbild zur Erlauterung der 

erf indungsgemafien Modifikation durch die Verwendung 
von Aspekten, 



Figure 3 ein Blockschaltbild zur Erlauterung des 

erf indungsgemaSen Einfugens von Migrierbarkeits- 
30 Funktionalitat und 

Figure 4 ein Blockschaltbild zur Erlauterung der 

erf indungsgemaSen Modifikation durch den Einsatz von 
Templates, Filtern und Patterns. 

35 

In Figure 1 ist ein Gesamtblockdiagramm zur Erlauterung der 
Erfindung dargestellt, bei dem zunachst ein Quellcode SC 
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durch einen Konverter COW in einen in einer Meta- 
Auszeichnungssprache f ormulierten ersten Code CodeML 
umwandelt wird, wobei der Quellcode SC bei sofortiger 
Kompilierung einen Byte Code bzw. Binarcode B ergeben wurde. 
Der in der Meta-Auszeichnungssprache dargestellte Code CodeML 
wird nun auf dem Wege einer Transformation T ausschliefilich 
durch die Verwendung von Transf ormationsregeln TR 
modifiziert, welche aus Bedingungen C und/oder Logik L 
und/oder Code-Fragmenten CF bestehen, wodurch sich ein 
zweiter ebenfalls in der Meta-Auszeichnungssprache 
f ormulierten Code CodeML* ergibt. Ein weiterer Konverter 
RCONV wandelt nach der Transformation den Code CodeML* in 
einen Quellcode SC* zuriick, der typischerweise in derselben 
Sprache wie der Quellcode SC formuliert ist. Durch einen 
Compiler COMP wird schlieSlich der modifizierte Code SC* in 
einen modi fizier ten Byte Code B* oder aber gleich in einen 
ausfiihrbaren Binarcode umgewandelt. Wesentlich ist hierbei, 
dass sich der Byte-Code B* prinzipiell vom Byte-Code B 
unterscheidet bzw. dass der Quellcode nicht nur in seiner 

Darstellung, sondern auch in seinem Programmablauf geandert 
wurde . 



Der Quellcode SC und der modifizierte Quellcode SC* sind 
beispielsweise in der Programmier sprache Java und die Codes 
CodeML und CodeML* sind beispielsweise in der Meta- 
Auszeichnungssprache XML formuliert, wobei „XML" fur Extended 
Markup Language steht. 

Die Transformation T, z. B. eine Extended Stylesheet Language 
Transformation oder XSLT, wird durch Transf ormationsregeln 
TR, z. B. innerhalb von XSL (Extended Stylesheet Language) 
Dateien beschrieben, wobei bspw. die in XSL f ormulierten 
Regeln TR u.a. beschreiben wie der in XML-codierte Quellcode 
CodeML mit dem Code-Fragment CP kombiniert wird, um einen 
neuen modif izierten Quellcode CodeML* mit integriertem CP, 
oder eine Abwandlung davon, zu bilden, welcher nun 



I 
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beispielsweise zusatzliche Logging-Funktionalitat enthalten 
kann. 

In Figure 2 ist ein erstes Ausf uhrungsbei spiel dargestellt, 
bei dem die Trans format ionsregeln TR speziell Aspektregeln AR 
nach Aspektorientierter Programmierung (AOP) entsprechen, die 
in der Aspect J- Spr ache ausgedriickt mindestens einen Pointcut 
PC und/oder mindestens einen Advice-Type AT und/oder 
mindestens ein Advice-Body AB enthalten und in . ihrer 
Reihenfolge den Bestandteilen aus Figure 1 zugeordnet werden 
konnen . 

Auf diese Weise kann eine (werkzeugunabhangige) sogenannte 
AOP realisiert werden, die im Vergleich zu anderen 
15 Losungsvarianten, beispielsweise Aspect J, keinen zusatzlichen 
Overhead im generierten Code CodeML* erzeugt und nicht den 
iiblichen Einschrankungen (extra Kompiler, Syntax, usw. ) 
existierender Aspektsprachen unterliegt. 

w 

2 0 Als Aspekt bezeichnet man in AOP eine Einheit, die 

uberkreuzende Anliegen (crosscutting concerns) z.B. ein 
Logging, modularisiert und an einer Stelle kapselt. Der 
entsprechende Code, der bisher mehrere Module durchzog, wird 
hierbei mit Hilfe eines einzigen Aspekts zusammengef uhrt . 



Die im Anhang bef indlichen Programmauf listungen Listing 1 bis 
Listing 5 zeigen dies an einem konkreten Beispiel, bei dem 
zunachst die in Listing 1 enthaltene Datei 
TestCalculator . java in eine XMD-Darstellung 

TestCalculator .xjava konvertiert wird. In Listing 3 erfolgt 
die Beschreibung eines Aspektes in Form einer Datei 
LoggingAspect .xsl, die alle notwendigen Transformationsregeln 
enthalt und dafur sorgt, dass jede Methode, die ein „cal w in 
ihrem Namen tragt, gefunden wird und zu Beginn der Ausfiihrung 
35 dieser Methode ein Druckbefehl System, out .print In („calculate 
begin") und am Ende der Ausftihrung dieser Methode ein 
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Druckbefehl System. out .print In (, calculate end* 1 ) eingesetzt 
wird. 

Sollen z.B. in alien 151 Klassen eines Projektes, alle 
Methoden die dem Muster „cal XA entsprechen, also z.B. public 
String calcValues ( ) o. a., dazu veranlasst werden, eine 
System-Ausgabe beim Eintritt und Austritt zu tatigen, so 
werden zunachst mit 

match="* [ (name() = 'curly ) and (ancestor : : method [contains (name, 'cal' ) ] ) ] » 
alle Methoden mit dem ff cal tt - Muster ausgewahlt, mit 

<expr> 
<paren> 

<dot><dot><name>System</naine><naine>out</naine></dot><name>println</naine></dot> 
<exprs> 

<expr> 

<xsl : text> "</xsl : textxxsl : value-of select= n . . /name u /><xsl : text> begin n </xsl: text> 
</expr> 
< / exprs> 
</paren> 
</expr> 

ein Statement "System. out. println(%Name der Methode% + « begin 11 ) 
z.B. System. out .prlntln( "calculate end" ) , eingef ugt , mit 

<xsl:copy-of select= n * M /> 

der urspriinglichen Code der Methode eingefiigt und mit 



<expr> 
<paren> 

<dotxdotxname>Sys t em</ name ><name> out < /namex /dotxname>print ln</namex/dot> 
<exprs> ' ' ~ 

<expr> 

<xsl : text> D </xsl : textxxsl j value-of select=° . . /name"/ xxsl : text > end"</xsl : text> 
</expr> 
</exprs> 
</paren> 
</expr> 



ein Statement "System, out. print In (^Name der Methoden + "end")", z.B 
System, out . print In ( "calculate end" ) eingef ugt . 



2003 P 02695 



6 

Anstatt also in alien 151 Klassen eine entsprechende Logging- 
Ausgabe zu veranlassen, kann dies hier innerhalb eines 
Logging-Aspektes an einer Stelle erfolgen. Anderungen miissen 
so auch nur an einer Stelle vorgenoinmen we r den . 

■ 

Figure 3 betrifft ein zweites Anwendungsbei spiel der 
Erfindung, bei dem ebenfalls aus einem Quellcode CodeML durch 
die Transformation T ein trans formierter Code CodeML* erzeugt 
wird, welcher nun einen Mechanismus zur Sicherung (OLD) bzw. 
Ermittlung (NEW) mindestens eines Zustandes fur die 
gewunschte (Versions) Migration en thai t. Die 
Trans f ormationsregeln TR sind in diesem Fall derart 
ausgebildet, dass sie als Migrationsregeln MR bezeichnet 
werden konnen und neben C und L zusatzlich mind, ein 
Fragment, sogenannte Checkpoints CP, zur Generierung (CP 
Write) bzw. zum Einlesen (CP Read) von Zustanden (CP Data) 
enthalten, die eine Migration von einer alteren Version B*OLD 
auf eine neuere Version B*NEW ermoglichen. 

Die fur eine Migration erf orderliche Formatkonvertierungen 
der zu xibergebenden Systemzustande konnen hiermit ebenfalls 
beriicksichtigt werden. Zukunftige Migrationen brauchen 
hierdurch nicht schon im Vorfeld beriicksichtigt zu werden, 
wodurch der Testaufwand und diesbeziigliche potenzielle 
Programmfehler in friihen Prograitimversionen vermieden werden. 
Durch eine Automatisierung der Migration werden menschliche 
Fehler vermieden, da die Migration wesentlich systematischer 
erf olgt . 

In Figure 4 ist ein drittes Aus fiihrungsbei spiel in mehreren 
Untervarianten dargestellt, bei dem ebenfalls ein in XML- 
codierter Quellcode CodeML durch eine Transformation T in 
einen modif izierten CodeML* umgewandelt wird. Die 
Transformation T wird hier jedoch durch Trans f ormationsregeln 
TR bewirkt, die in jeder Variante aus mindestens C und L 
bestehen und wie bei der Umsetzung von Templates TP 
zusatzlich mindestens ein Template-Fragment TPF enthalten, 
bspw. fur die Umwandlung in eine EJB (Enterprise Java Bean) 
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und bei der Umsetzung von Patterns P mindestens ein Pattern- 
Fragment PF besitzen, bspw. fur die Anwendung von Proxy, 
Factory oder Singleton Patterns. Bei der Realisierung von 
Filtem FI genugen C und L, da hier nur Code entfernt wird 
und so bspw. iiberflussige Output-Statements oder Kommentare 
beseitigt werden konnen . 

Durch die entsprechende Anwendung von proxy patterns konnen 
local calls in remote calls oder in ahnlicher Weise local 
classes in EJB-classes (Enterprise Java Beans) umgewandelt 
werden . 



Umgekehrt kann mit Hilfe einer Transformation T und 
entsprechenden Regeln TR aus dem XML-codierten Quellcode 
JavaML oder einem Fragment dieses Codes auch ein giiltiges 
Template TP generiert werden, das als Vorlage fur anderen 
Quellcode anwendbar ist. 

Die oben genannten Auspragungen des erf indungsgemafien 
Verfahrens konnen einzeln und in beliebiger Reihenfolge 
nacheinander erfolgen. 

Durch das erf indungsgemaSe Verfahren ergeben sich noch eine 
Reihe von zusatzlichen Vorteilen, wie beispielsweise: 

1. Es konnen schnelle und flexible Anderungen im Quellcode 
vorgenommen werden. 

2. Es ist nur ein System fur Problemstellungen wie 
Patternanwendung, Migration, AOP, Filtering, etc. 
erforderlich und nicht eine Reihe verschiedener teilweise 
proprietarer Werkzeuge. 

3 . Das Verfahren basiert auf Standards wie XML und XSLT und 
ist hinsichtlich der Konvertierbarkeit in andere 
Programmiersprachen geringeren Beschrankungen unterworfen als 
andere Verfahren zur Modifikation von Quellcode. 
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4. Selbst fur spezielle und komplizierte Quellcode- 
Modifikationen sind keine proprietaren Speziallosungen 
erforderlich, sondern es konnen hierfiir existierende 
Standards wie XSLT, XPath und Xqpiery genutzt werden. 

5. Diese Art der Modifikation erlaubt die Erstellung von 
Hierarchien u.a. durch die Moglichkeit der 
Hintereinanderausfuhrung (Pipelines) mehrerer 

Transf ormationen . 

7. Die Transf ormationen konnen als allgemeine 
Transformationen fur eine Wiederverwendung in XSLT-Dateien 
gespeichert werden, so daS Bibliotheken z.B. fur bestimmte 
Ablaufe entstehen konnen. 

8. Es kann eine XML-Reprasentation des Quellcodes in einer 
XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer 
XSLT in einfacher Weise an die jeweiligen Kundenbedurf nisse 
angepasst werden. 

9. Durch die Verwendung der Standards XmlSchema Oder DTD oder 
entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , 
auf bestimmte Korrektheitsaspekte hin, uberpriift (validiert) 
werden . 

t 

10. Ubliche XML-Visualisierungstools Tools konnen zur 
einfachen Bearbeitung bzw. Visualisierung und Bestimmung von 
Beziehungen im Code verwendet werden. 

11. Dauerhafte XML-basierte Programmbibliotheken, die XPath- 
Anfragen unterstutzen, konnen die Wiederverwendung von Code 
durch besseres Auffinden eines Codes bzw. von Code-Fragmenten 
oder Templates verbessert werden. 



i 



t 
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Anhang 
5 Listing 1: TestCalculator.java 



10 



public class TestCalc\ilator{ 
private int z; 

public void calculate ( int x, int y) ( 
z a x*y; 

} 

} 



1 5 Listing 2: TestCalculator.xjava 




25 



30 
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<?xml version= "1 . 0 ■ encodings "OTP- 8 ■ ?> 
<java> 
<class> 

<modifiers><public/x/modifiers> 
<name>Tes teal cul at or < / name> 
<block> 
<var> 

<modifiers><private/></modifiers><type><int/></typexname>z</name> 
</var> 

<method> 

<modi f i er s xpubl i c / >< /modi f i er s > 
< typexvoid/ x / type> 
<name>calculate< /name> 
<params> 

<param>< typexint /></ typexname>x< /nam ex /param> 
<param> < typexint /></ type><name>y< /namex /par ain> 

</params> 

<curly> 
<expr> 
<a> 

<name>z</name> 

<plusxname>x< /namexname>y< /namex /plus > 
</a> 

</expr> 
</curly> 
</method> 
</block> 
</class> 
</ java> 



Listing 3: LoggingAspectxsI 



50 



<xsl: stylesheet version=»l . 0 ■ xmlns:xsl="http: / /www. w3 . org/ 1999 /XSL/Trans form" > 



55 



<! — ********************************* 

*** copy template ** 
***************** **************** > 

<xsl : template mat ch= " * M > 

<xsl : copyxxsl : apply-templates/x/xsl : copy> 
</xsl : template> 



60 



< ! ********************************* 

*** logging aspect x ** 

**************************** A ** * * > 

<xsl: template match="* [ (name ( ) = 'curly ) and (ancestor : 
<xsl:copy> 



: method [contains (name, 'cal' ) J ) ) •»> 



» 
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<expr> 
<paren> 

<dot><dot><name>System</name><name>out</name></dot><name>println</name></dot> 
<exprs> 

<expr> 

<xsl: text>"</xsl: textxxsl : value- of select=°. . /name" /xxsl : text> begin" < /xsl : text > 
</expr> 
</exprs> 
</paren> 
</expr> 

<xsl:copy-of selects"*" /> 
<expr> 
<paren> 

<dot><dot><name>System</name><name>out</name></dot><naine>println</nanie></dot> 
<exprs> 

<expr> 

<xsl : text> °< /xsl: text xxsl: value-of select=°. . /name" /xxsl : text> end B < /xs 1 : text > 
</expr> 
</exprs> 
</paren> 
</expr> 
</xsl:copy> 
</xsl : template> 
</xsl:stylesheet> 



Listing 4: TestCalculator*.xjava 




<?xml version= tt l. 0" encodings ■ UTF- 8 *?> 
30 <java> 

<class> 

<modi f ier s xpubl i c / x /modi f ier s > 

<name>TestCalculator</name> 
<block> 
3 5 <var> 

<modifiersxprivate/x/modifiers><typexint/></type><naine>z</name> 
</var> _ 

<method> 

<modifiers xpubl ic/x /modi f xers> 
40 <type><void/x/type> 

<name>cal cul at e< / name> 
<params> 

<paramx typexint /></ type><name>x< /namex /param> 
<paramx typex int /></ typexname>y< /namex /param> 
</params> 
<curly> 



<paren> 

<dot xdot ><name>System< /name xname> out < /namex /dot ><name>print ln< /namex /dot > 
<exprsxeacpr> "calculate beg±n n </eraprx/exprs> 
</paren> 
</expr> 
<expr> 

,r <a> 

■^^ <name>z</name> 

<plusxname>x< /namexname>y< /namex /plus > 
</a> 

</expr> 
£H <e*pr> 
O U <paran> 

<dot > <dot xname >Syst em< /namex name >out < /name >< /dot ><name>pr int ln< / name> </ dot > 
<exprsxexpr>« calculate end M </exprx/exprs> 
</paren> 
</eacpr> 
65 </curly> 

</method> 
</block> 
</class> 
</ java> 

70 
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Listing 5: TestCalculator*.java 

public class TestCalculator{ 
private int z; 

public voicl calculateUnt x, int y) t 

System, out .priutln ( " calculate begin* ) ; 
z = x+y ; 

System, out -print In (* calculate end") ; 

} 

> 



» 



2003 P 02695 




12 

Patentanspriiche 

1. Verfahren zur Transformation von Quellcode, 

5 - bei dem ein in einer erst en Programmiersprache f ormulierter 
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache 
formulierten ersten Code (CodeML) umgewandelt wird, 

- bei dem eine Transformation (T) nur in Abhangigkeit von 
Trans forma tionsregeln TR in einen in der Meta- 

10 Au s z ei chnungs spr ache formulierten zweiten Code (CodeML*) 
erfolgt und 

- bei dem dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 
formulierten zweiten Quellcode (SC* ) verwandelt wird, wobei 

15 sich der erste und der zweite Quellcode in ihrer 
Funktionalitat (B, B* ) unterscheiden . 

2. Verfahren nach Anspruch 1, 

bei dem die Trans forma tionsregeln (TR) mindestens eine 
20 Bedingung C und einen Logikbestandteil L und/ oder 
Codefragment CF selbst enthalten. 

3 . Verfahren nach Anspruch 1 oder 2 , 

bei dem die Transf ormationsregeln TR als Aspektregeln AR nach 
AOP bezeichnet werden und/oder C und/oder L und/oder CF 
mindestens einen Pointcut PC und/oder mindestens einen 
Advice-Type AC und/oder mindestens einen Advice-Body AB 
bilden. 



30 



4. Verfahren nach Anspruch 1 oder 2, 

bei dem die Transf ormationsregeln TR als Migrationsregeln MR 
bezeichnet werden und/oder C und/oder L und/oder CF 
mindestens einen Read und/oder Write Checkpoint in CodeML* 
unter Ausfuhrung der Transformation T generieren. 
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5 . Verf ahren nach Anspruch 1 oder 2 , 

bei dem die Trans formationsregeln TR mindestens ein Fragment 
in Form eines Templates TPF und/oder und/oder mindestens 
eines Patterns PF entalten, bei denen mit Hilfe der 

■ 

Transformation T mindestens eine oder keine Codeentf ernung 
und/oder Codeveranderung und/oder Codeerzeugung im CodeML 
erfolgt, und sich aber mindestens ein Codeteil von CodeML* 
gegenuber CodeML andert. 

6 . Verf ahren nach Anspruch 1 oder 2 , 

bei dem in den Transf ormationsregeln TR kein Codefragment CF 
existiert und/oder C und/oder L als mindestens ein Filter 
benutzt werden, welche den nach der Transf ormtion T 
entstehenden CodeML* um mindestens einen elementaren 
Bestandteil bereinigen. 

7. Verf ahren nach den Ansprttchen 1 bis 5, 

bei dem CF mindestens einen Programmteil zur schritthaltenden 
Dokumentation des Programmablauf s oder des Ablauf s von 
Programmteilen enthalt, und dieser durch die Transformation T 
in gleicher oder abgewandelter Form an mindestens einer 
Stelle in CodeML* vorkommt. 

8 . Verf ahren nach Anspruch 4 , 

bei dem TR derart ausgebildet ist, dass mit Hilfe der 
Transformationen T ein Mechanismus zur Sicherung mindestens 
eines Systemzustandes in den zweiten Quellcode (CodeML*) 
eingebracht wird, um eine Migration in andere Versionen zu 
ermoglichen. 

9. Verf ahren nach einem der vorhergehenden Anspriiche, 
bei dem die Programmi er sprache des ersten und zweiten 
Quellcodes Java und die Meta-Auszeichnungssprache XML ist und 
bei dem die Transformation mit XSLT erfolgt. 
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10. Verfahren nach Anspruch 1 oder 2, 

bei dem mit Hilfe der Trans format i6n T aus dem ersten Code 
oder einem Fragment des ersten Codes mindestens ein Template 
TP gebildet wird, welches im Rahmen des Anspruchs 5 verwendet 
5 werden kann. 

11. Anordnung zur Transformation von Quellcode, 

- bei der ein erster Konverter (CONV) derart vorhanden ist, 
dass ein in einer ersten Programmiersprache formulierter 

10 Quellcode (SC) in einen in einer Meta-Auszei chnung s spr ache 
formulierten ersten Code (CodeML) umgewandelt wird, 

M - bei der ein Prozessor derart vorhanden ist, dass der CodeML 

W durch eine Transformation (T) nur in Abhangigkeit von 
Trans format ionsregeln (TR) in einen in der Meta- 

15 Aus z ei chnungssprache formulierten zweiten Code (CodeML*) 
umgewandelt wird und 

- bei der ein zweiter Konverter (RCONV) derart vorhanden ist, 
dass dieser zweite Code in einen in der ersten 
Programmiersprache oder einer anderen Programmiersprache 

20 formulierten zweiten Quellcode (CodeML*) verwandelt wird, 
wobei sich der erste und der zweite Quellcode in ihrer 
Funktionalitat bzw. Inhalt(B # B*) unterscheiden. 
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Zusammenf assung 

Verfahren und Anordnung zur Transformation von Quellcode 

Die Erfindung besteht im Wesentlichen darin, dass der in eine 
Meta-Auszeichnungssprache, beispielsweise XML, konvertierte 
Quellcode mit einer in seinen Elementen standardisierten und 
ubersichtlich beschreibbaren Transformation, beispielsweise 
XSLT, derart transf ormiert wird, dass, nach einer 
Ruckkonvertierung aus XML in die urspriingliche 
Programmiersprache, ein neuer Quellcode entsteht, bei dem 
nicht nur die Darstellung, sondern auch der eigentliche 
Programminhalt bzw. die Funktionalitat entsprechend den 
Transf ormationsvor schri f ten verandert wurde. Hierbei sorgt 
nur die in den Transf ormationsvorschr if ten enthaltenen Regeln 
fur eine Modifikation des ursprunglichen Quellcodes, wodurch 
beispielsweise der Code um Logging-Funktionalitat oder eine 
Migrierbarkeits-Funktionalitat erganzt wird. 
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